NANI!?
Okay you fuzzmuppet, let me tell you how it's gonna be from now on so you get to learn your place around here!


KOKOwaDOKO/?/??
This here should be the folder containing inindo_edit.exe, /disasm_map/... and /rom_sram/(empty)
I would argue that an individual whom is of sound and sane mind should copy the ROM (.sfc?) and SRAM (.srm?) file to the aptly named directory, BUT HEY WHAT DO I KNOW ANYWAY?

When you launch inindo_edit you'll need to load the ROM, SRAM. These should be single files and easy to understand.


LOADING THE ROM DATA:
Load the ROM data you data-dingus. Otherwise you'll get annoyed by text captions like "NO ROM DATA" or nulls "" and weird names like "data element 5". You can load ROMs that aren't ININDO, but you can't really expect inindo_edit to work with them or get mad when it doesn't.


LOADING AND SAVING THE SRAM DATA:
When you initially load an SRAM this will register the path and filename for use by the quickload/quicksave functions. Afterward you can use these functions to quickly reload from or save to the same file. You'll often find that if you run emulators at the same time they may read/write the SRAM file arbitrarily, while frustratingly few emulators provide options to do so manually at user discretion. Please keep this in mind while you're tearing your hair out trying to figure out what's gone wrong. (I suggest closing/ending the emulator fully, using inindo_edit and then reopening the emulator for reliable function.)

In addition it's possible to export your modified save to a new file. This feature is mostly useful for storing a reference backup for later comparison.


EXPORTING THE MODIFIED ROM:
YOU CAN'T EDIT THE ROM DATA FROM THE GUI YET, DUMMY so like w/evs pshaw


EXPORTING THE DISASSEMBLY OR BITMAP DATA:
The database can be divided into multiple files using #include to ease reading and editing the data.

In the structure I've used: inindo.db.txt is the root file that imports all the others. The preprocessor doesn't (yet?) support hierarchical relative path, so absolute path must always be used or you're limited to storing all the files under the same path.

When you export files you'll be asked for the destination path. Sub-directories will be created here; "disasm/" for disassembly and "bitmaps/" for bitmaps. In addition a few other files are generated. Many of the generators which have been used to populate the included database aren't directly accessible from the GUI.

I don't recommend using the disassembler without the associated data for human-readable names. If you run the disassembler without the database it will generate some additional lists of unknown functions which have been identified automatically. Data references aren't exported automatically as the generated data lacks the level of validity that the function lists do. In the future the code-path-tracing and cross-referencing abilities of the disassembler may be improved.


HOW NOT TO FREAK OUT:
This should all work correctly as far as I'm aware; Bugs may exist and things could go wrong. Let me know if so and I might be able to help. It's never the known unknowns that get you. What you really ought to be worried about are the unknown unknowns, satanic mind-control rays cast from the moons of Jupiter and the razor-sharp edge of ketchup flavored potato chips. Put on your tinfoil hat and dive into the safety of your bunker to hunker down and escape from crazy town.
